home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HAM Radio 3.2
/
Ham Radio Version 3.2 (Chestnut CD-ROMs)(1993).ISO
/
packet
/
pk232com
/
g3zcz.lan
< prev
next >
Wrap
Text File
|
1987-11-09
|
41KB
|
925 lines
PACKET RADIO - THE USER INTERFACE PAGE 1
Presented at the AMSAT-NA 1987 Space Symposium.
PACKET RADIO - THE USER INTERFACE
By Joe Kasser G3ZCZ
Introduction
The majority of the thinking and the software development in
Packet Radio to-date has been in the area of the BBS and in
message handling. Everyone assumes that messages exist yet ignore
how those messages got into the packet radio network in the first
place and how they get out of it later. This paper addresses that
neglected aspect of the gendre; in other words, the User Interface
or the Personal Packet Terminal Program (PPTP) and the environment
in which it resides.
The Packet Radio Medium.
The Packet Radio Medium consists of what is happening in a given
local area on a frequency channel time-shared by a number of
amateur radio stations. It is a multiple access or distributed
situation which has so far been treated almost the same as a
single point-to-point situation such as the telephone line.
Unlike in a telephone based network, many of the stations in the
network can, in real time, see information passing between other
stations in that network. [1,2] Whereas the telephone based net
may be considered as a centralized network in which everyone on it
is connected to a single host, the amateur radio packet Local Area
Network (LAN) is spread over a geographical area and should be
considered as a distributed network. Packet Radio software to-
date has been designed for a one-on-one connection ignoring the
one-on-many capabilities available in a distributed LAN.
Consider the medium itself, Packet Radio is an ideal MESSAGE
MEDIUM. While there is place for keyboard operation, Packet Radio
really shines when passing messages. The Packet Radio operator is
really interacting with the LAN. The TNC and PPTP can be
considered as a single element between the human operator and the
LAN, so that any discussion of the user or human interface must
take into account activity on the LAN.
Packet Radio LAN Capability
VHF Packet radio systems can be considered as part of a LAN in
which messages can be left by one station in a computer belonging
to a second station. At HF the same is true, but the area of the
LAN becomes greater.
The fundamental problem within the LAN is that people can only
send and receive messages to or from any specific station when
that station is on-line. To compensate for this, Packet LAN
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 2
development parallelled that of the centralized telephone network.
BBS stations were developed which allowed both messages and
bulletins to be stored for later retrieval. As the requirement for
bulletin messages is real in the Radio Amateur environment and the
centralised LAN concept meets the requirements of both bulletin
and point-to-point messages, the distributed LAN approach for
point-to-point messages in the main seems to have been ignored.
Most Amateur Packet Radio Stations use computers to interface the
TNC to the LAN. As there is all this computer power sitting in the
shack, why not take advantage of it.Let us include within the
PPTP software, which takes into consideration both the
characteristics of the distributed LAN and how optimum use can be
made of them for the user.
The User Interface.
This is defined as what the user types at the keyboard and sees on
the screen of his computer when it is connected to a working TNC
which by definition is part of the LAN. When somebody first gets
a TNC, he gets a 'black box' which comes with a manual that seems
bigger than than the box itself. The instructions on how to
connect it to a transceiver may be easy enough to follow, but then
the instructions on what to type and when, are a nightmare.
The TNC can operate in a Command Mode, in which you tell it to do
something, or in a Converse Mode in which you are using it to pass
text of some kind to other stations. Many newcomers confuse the
two TNC modes. If you monitor the packet channels you will
recognize command mode TNC instructions on the air, and when you
use the TNC, well I'm sure that you still get, now and again, an
'Error' message when you type something thinking that you are in
the Converse Mode but are really in the Command Mode.
The Personal Packet Terminal Program [PPTP].
Most of the commands that affect the parameters within the TNC are
normally never touched. In fact once 'CONNECT', and 'DISCONNECT'
have been figured out, and the difference between the Command and
the Converse Modes (and how to get from the one to the other) are
understood, the newcomer is able to use Packet Radio. From this
time on he rarely uses any of the other TNC commands with the
possible exception of 'MH'. Even the ones that should be adjusted
when changing from VHF to HF operation most often never are.
From a human factors point of view, Packet Radio under these
conditions is dissapointing. Tests have shown that the attention
span of a person sitting at a terminal is about 2 seconds. In
conventional RTTY, or AMTOR operation, the data communications
rate is might be slow but at least something is happening all the
time. In keyboard to keyboard Packet Radio contacts, often
minutes seem to pass before the next packet shows up on the
screen.
The PPTP's most commonly used at present on PC's are either YAPP
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 3
[3] or conventional telephone modem driver programs. There is no
smart PPTP. The need for "smart" PPTP's is however being
perceived. The Mini BBS seen on the air is one example. Another
example noticed in London and in Israel, is that stations equipped
with IBM PC's or clones start off by using BBS programs as their
PPTP. On one evening in London in August 1987 G3RWL taped about
10 BBS's, point to point direct connects, stations doing muti
digipeat connects to other stations as well as to the BBS's all on
the same channel and all using it simultaneously. It is a wonder
that any traffic got through.
A PPTP program written in Turbo Pascal, named PK232COM, that is
optimized for the radio amatuer LAN has been developed for the MS-
DOS, IBM PC series of microcomputers. Although first written for
the AEA PK232 Multi-Mode Data Controller, taking advantage of some
of the specific commands built into the PK232. It has since been
modified so that most of the PPTP Packet Radio functions will also
work on a TNC2. The following list contains much of what this
PPTP does both as the user interacts with it, and how it performs
LAN related activities.
* Function Key Control
The commands to the TNC lie somewhat in between a mixture of
operating, configuring and debugging. This PPTP relieves the
user of figureing out how to tell the TNC to do what he wants
it to do. It takes advantage of all the computing power at
the user's fingertips (literaly) and uses software which may
be located either in the TNC or in the PPTP, but totally
transparent to the user. The user in fact never has to tell
the TNC to go into or out of the command or converse modes.
The user tells the PPTP what he wants done by means of
function keys, and the PPTP figures out what to tell the TNC
to do the job.
* Terminal modes.
There are four single connect modes and two multiple connect
modes of operation, as follows.
1 SOLO
In this mode, you will only see messages addressed to you.
You will only get messages from people who connect to you.
(This corresponds to 'MONITOR OFF').
2 TRAFFIC
In this mode you will see most of the traffic on channel.
You can use this mode to check that the TNC is working.
(This corresponds to the PK232 'MONITOR 4' [4] or 'MONITOR
ON').
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 4
3 CQ/BEACON
In This mode, you will see CQ and BEACON packets on the
channel. (This corresponds to the PK232 'MONITOR 1' and only
works on the PK232.
4 READ THE MAIL
In this mode the terminal is set to display the contents of
packets without the headers for selected stations. Apart from
being able to copy both sides of a QSO, you can read the mail
on a BBS or other stations and get BBS bulletins without
connecting to that BBS your self. This cuts down on the
number of messages sent on the LAN, since more than one
station can copy the same Bulletin at the same time. This
corresponds to 'MONITOR OFF' and 'MBX' <callsign> and only
works on the PK232.
5 MULTIPLE CONNECT CAPABILITIES
Advantage is taken of the 10 I/O streams in the TNC for
multiple access modes as follows;
5.1 The Individual Multi Connect Mode
This is the normal Multi Connect Mode as described in the
TNC manual. Here you are connected to up to 10 stations
and will send different traffic to each of them. Each time
you wish to send something to a particular station, you must
select the IO channel the station is connected on before
typing the text or sending the file.
5.2 The Conference Multi Connect Mode.
In the Conference Mode on the other hand, everything that
you type at the keyboard is transmitted to each station that
you are connected with. Thus if you are linked to two
stations each line will be packeted twice by the TNC. You
don't have to worry about sending the wrong thing to the
wrong person, as they will all get the stuff. This mode
should be ideal for DX nets, 'contest spotting' and public
event support.
* Automatic Answering Machine capability with display of
message queue.
The PPTP incorporates a smart "answering machine" facility.
You can leave messages on your system for different stations.
When someone connects to you, if you left a message for him,
he (or she or even it as the case may be) will receive it
automatically. No one else should normally be able to
download that message.
To ensure that people know that you have left a message for
them, a 'MAIL for' list is loaded into your Packet Beacon and
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 5
transmitted every 30 minutes. If no mail is pending then
beacon transmissions are inhibited. This conforms to good
operating practice on crowded channels (at least inhibiting
the beacon does).
* Automatic Capture-to-Disk
All traffic received during connects is stored onto disk.
Provision is also there for manual capture of any traffic
monitored on the screen.
* Automatic logbook entries for Connects.
All connects are logged into a separate logbook file. The
Logbook file is capable of being processed by a database
Logbook Package.
* Printer on/off control.
The PPTP can print incoming information and will
automatically shut off the printer on disconnect.
* Alert signal
The PPTP contains an Alert function to let you know when
someone shows up on LAN. It is active when disconnected and
the terminal set for 'TRAFFIC'. The PPTP scans the packet
headers received from the TNC, and, when it sees a packet
originated (or digipeated if the MRPT parameter in the TNC is
set to 'ON'), by the station whose call has entered as the
'Alert' call, sounds an alarm at the console. The Alert
function should (but can't be without getting at the TNC
firmware) be independent of the terminal communications mode.
* Indicator that a specific station designated as the 'target'
call connected while you were away.
This function saves you dumping the capture-to-disk file to
check if traffic has been received from a particular station
who promised to send you some data that you need urgently.
* Split screen terminal display, at least 3 Windows displaying
Incoming text, Outgoing text and Status Information.
The Status information includes the call of the Station you
are connected with (if any), PPTP mode and status, number of
connects, number of messages outstanding, PPTP configuration,
Alert and Target calls.
When the PPTP sees a connect by the station whose call you
have entered as the 'Target' call, it sets the flashing
Connect Counter display to show a 'happy face'.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 6
* Simplified keystrokes for connect paths and loopbacks.
Connect path information may be stored in an ASCII text file
(PK232COM.DIR which is compatable to YAPP.DIR [3]) in the
following format.
Alon 4Z4ZB V 4X6AA
Milt 4X6AA
LR 4X6LR
hf-il 4x4hf v 4z4zb 4x4il
hf-rj 4x4hf v 4z4zb 4z4rj
You create this file with your wordprocessor in its non
document mode. You must leave AT LEAST one space character
between the key word and the connect path. When you attempt
a connect, the PPTP scans this file to see if what you typed
matches one of the key words (first word) on any line of the
file. It also ignores the case of what you typed in. If it
does not find the key word, it will try to connect with
whatever you typed in.
A LOOPBACK is when you connect to yourself through someone
else. You should use this to test a connect path when the
station you want to connect with is connected to a third
station. Instead of causing QRM to him by trying to connect
to him and getting a 'busy' signal if the path is good,
loopback using him as a digipeater to test the path. The
loopback should be performed with a minimum of keystrokes.
Thus to loopback through K8PNW you just have to use the
regular PPTP function key that does the connect operation
(Function key 7), but type '/K8PNW' (slash [callsign] instead
of [yourowncall] via [callsign]).
* Path determination to Dx station.
On VHF, if you want to establish a digipeat path to a
station somewhat out of your direct range, you need to know
which of the stations that you can connect with can hear
that desired DX station. If you could get a call monitored
(MH list) from the stations that you connect with, you would
be able to see if the station you are connected with has
heard your desired DX station. Thus as the TNC can't do
it, the PPTP is capable of being triggered to send its 'MH'
list to the connecting station.
By judicious use of this capability you can determine paths
to other stations. Note however, that just because one
station can hear another station, it does not mean that it
can work it. For example, the station you are connected
with may be using a power level of 1 watt or so, while the
station 200 miles away that it heard was using 100 watts.
Test the path yourself, or/and leave a message asking about
the reliability of the connect path between those two other
stations. The DX station also may not be on-line all the
time.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 7
* Remote File Downloading
There comes a time when you want to leave a file on your
system for someone to download later. For example, you have
the latest AMSAT or ARRL DX bulletin, and you want to pass it
on. You could pass it to selected people by copying the file
to individual messages which wastes a lot of disk space.
On the other hand you could tell people that the file was
available for downloading. You could do this either in the
CTEXT connect message line which everyone gets when
connecting to you, or in individual messages if you don't
want everyone to know about it. The PPTP is not designed as
a BBS, however it does have the capability for remote
downloading of files.
* Automatic Count of, and indication of Packet connects.
The counter shows the number of connects made to the PPTP
since you last reset the counter. Its a usefull indicator of
how much trafic has come in since you last looked at the
screen. The counter is resetable by means of a function key.
* Digipeat monitoring and capture.
Although the TNC can digipeat on its own, there may be times
when you want to know when you are being used as a
digipeater and to capture-to-disk the contents of any packets
digipeated through your station. (A typical example of this
situation is when stations on your 'forbidden country list'
digipeat through you and you may have a need to show what
data was "exchanged".) This capability is in the PPTP.
* Capable of automatic connect attempts to snatch a QTC.
In the disconnected state, the PPTP monitors 'QTC' lists and
when it sees its own call in one, automatically attempts a
connect to snatch the message. In this manner there is no
need to manually repeat connect requests to stations to whom
messages are addressed in the hope that they have joined the
LAN. When any station signs on to the LAN (ie the time when
the equipment is powered up), it will, within 30 minutes,
monitor a QTC list from every other station on the LAN and
download its own traffic. In fact in an ideal situation, all
one would have to do to "send" a message would be to leave it
in one's own PPTP which would then set the QTC list in the
Packet Beacon. The QTC_Snatch in the destination PPTP
function would take care of the message transfer.
In the PACSAT environment, the QTC_Snatch function would be
used to automate reception of messages at remote ground
station sites. When the spacecraft is within the
communications window of a ground station for which it has
traffic for and transmits a beacon 'QTC mail-for' list, the
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 8
ground station will automatically download its traffic.
As the QTC_Snatch may not be legal in certain countries, this
capability is only configurable at the time of loading the
program and is not reconfigurable on-line.
* Automatic Beacon Mode CQ caller.
The PPTP has the capability to call CQ repetitively and
either signal you when a reply is received or work the
connect and call CQ again after the disconnect.
This ROBOT feature is designed for DX-Peditions, special
event stations, meteor scatter, moonbounce, propagation
research beacons, areas of low activity and to enable "off-
channel" or random frequency HF Packet operation.
In case of abuse: if someone running the PPTP has their
beacon timer set too often, the PPTP can be shut down
remotely by someone connecting with it and telling it to
'QRT'. This takes them off the air for a while at least.
* Local Area Network (LAN) message store and forward.
The PPTP is capable of storing messages to be delivered in
the manner of a 'selective' answering machine. When someone
connects, any message pending is delivered without the need
for any further action. In case of some error a 'repeat
request' function is available.
All stations in the LAN should in the ideal case be able to
store messages for any other station in the LAN.
* Bulk dump (forwarding) of messages around the LAN.
There are many instances when the owners wish to take their
systems off-line yet still wish that their messages be
posted in the LAN. The PPTP thus contains a facility for
bulk 'dumping' of messages between different computers in the
LAN.
LAN Protocol (G3ZCZ Version)
The LAN has to be usable by all stations connected within it
no matter how smart or dumb a PPTP they are running. The
commands thus should be manual as well as function key
driven. The language used should be reasonably familiar to
Radio Amateurs and be capable of being used by those with
little or no knowledge of English.
In the G3ZCZ LAN environment, path determination and other
functions as well as messages transferrence may be performed
using elements of the Q code adapted into a High Level
Network Communications Language (NC/L) [1,2].
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 9
To receive a message, do nothing, you receive them
automatically when connecting/linking to another station. In
case of a problem you may request a repeat. You should also
normally not be able to read messages adressed to another
person. Bulletins are not considered as messages, they are
considerd to be files.
NC/L uses elements of the Q code in CAPITAL letters with a
':' character prefix and suffix (eg. :QSL:), so as not to
trigger responses in text. The PPTP does not respond to
lower case NC/L to allow 'help' information to be transmit-
ted on-the-air without also triggering a response.
Elements in use to-date in PK232COM Version 1.43 are (in
alphabetical order) as follows.
:EOF: End of message, (^Z is used in Packet, :EOF: is used
in AMTOR).
:QBM: To download a file.
:QJG: No more messages pending.
:QMH: To request a call monitored list ('MH').
:QNO: Error or function not present/active.
:QRV: Ready for message.
:QRT: To shut down a packet mode beacon station.
:QRU: To upload messages.
:QSL: Confirm receipt.
:QSM: To request a repeat of a message.
:QSP: To leave a message for another station.
:QTC: Messsage list.
Proposed extensions are as follows.
:QYU: YAPP format (binary) file upload.
:QYD: YAPP format (binary) file download.
NC/L In Use.
All command words in NC/L if requiring an extension, are
followed by one space character. The following words are
transmitted to a remote PPTP.
:QBM: To download a file, send :QBM: filename.type.
The filename.type is the file you want. For example
:QBM: ARRLDX.015
Note the single space character between :QBM: and the
file name. The PPTP is not designed as a BBS,
however if you leave a file or bulletin for someone
to download, you may tell them about it by leaving
them a message (which they will get automatically
when they connect) and no one else connecting will
know that it is there.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 10
:QMH: To request a call monitored list ('MH') from the
station that you are connected with, send :QMH:.
:QSM: To request a repeat of a message, send :QSM:.
You use this if the link was marginal and the connect
request got through but the data didn't.
:QSP: To leave a message for someone, send :QSP: callsign.
The protocol is as follows. When connected to someone
who has their computer configured as a host, if you
want to store a message you send the following
instruction to the other station :QSP: <callsign>
where <callsign> is the call of the station that the
message is for, not the callsign of the host station
in whose computer you are storing the message. Do not
use SSID's. [Note use only one space character after
the :QSP:].
For example if you want to store a message for 4Z4ZB,
or 4Z4ZB-1 or even 4Z4ZB/W3 in 4X6AA's computer which
is configured to Store and Forward messages, you would
first connect to 4X6AA and then send the request to
store the message as
:QSP: 4Z4ZB .
The other computer will respond either with a
statement saying that it is ready for you to go
ahead, or send a message saying that it can't comply.
If it is ready you get a positive reply in the the
form of :QRV: <callsign> which if you know the Q
code, means " I am ready to accept a message for
<callsign>".
At this time you may go ahead and send the message.
Use either a control Z (^Z) character or the
character sequence :EOF: followed by a carriage re-
turn (the ENTER key) to terminate the message.
Once you have completed the message, the other (host)
computer will either reply that the message has been
successfully stored or give you an error message.
If the message is stored and ready to be sent next
time the addressee connects to that computer, you
will see the response :QSL: on your screen. If
something went wrong, you will get back a negative
response taking the form :QNO: followed by a number.
The number tells you why the operation failed.
:QRT: To shut down a packet mode robot or beacon station
which is causing QRM, connect with that station and
tell it to 'QRT' by sending :QRT:.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 11
:QRU: To upload or download messages from one PPTP to
another, send :QRU:.
When the QRU function is invoked locally or remotely,
either by you or for example, by 4Z4ZB connecting to
you and sending you the command :QRU:, any messages
addressed to any stations for which you have
designated him as a 'Store and Forward' node (MBX)
will be transferred from you to 4Z4ZB just as if you
QSP'd the messages manually.
You may only use the QRU function with stations
which you have pre-designated as Store and Forward
nodes (MBX). Everybody designates their own Store
and Forward nodes based on the 'MH list' of the
station being designated. The is little point in
designating someone as a 'Store and Forward' node for
stations that they cannot connect with, unless they
happen to be in a digipeat path for inter LAN message
passing.
While QRU gives you the capability to bulk upload
messages to another station in your local area, when
you take your machine off line, it may also be used
to transfer messages between two LANs (such as the
Baltimore and Washington DC Areas) via well sighted
gateway digipeaters. It can also be used for long
distance transfers but in a very inefficient manner.
:QNO: 'NO' or error
QNO Error Values.
The following error numbers are associated with
message store and forward operations.
? Non valid NC/L word.
1 Computer not configured as Store and Forward
system.
2 Requested ASCII file/ message (:QBM:) does not
exist.
3 You made an error in the name of the callsign
for whom the message is intended (It must be at
least 3 characters long).
4 File creation error in host system.
5 Error occurred during reception and storage of
message. Could be that the computer ran out of
space on the disk, or something else went wrong
in storing the message.
6 :QRU: You are not authorised as a store and
forward mailbox.
7 :QRU: Error in opening MBX file.
8 :QRU: Error in closing MBX file.
9 :QRU: Sequence Error in callsign of message to
go. The bad callsign will be shown after the
error number.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 12
90 NC/L defined function not implemented in this
release.
99 PK232COM compatable program, but requested
function has not been implemeted.
:QJG: The QRU sequence is complete. There are no more
messages pending.
:QRV: <callsign>
The computer is ready for you to send the message.
End the message with a control Z (^Z) character, or
the sequence :EOF: .
:QSL: <callsign).
Confirms receipt of message to that callsign.
:QTC: Messsage list.
This precedes a list of callsigns for whom messages
are stored up on a computer. It is used in Packet
Beacon transmissions.
PROPOSED EXTENSIONS
:QYU: YAPP format file upload.
:QYD: YAPP format file download.
Message Format
When you QSP a message, it is stored just as if you had left
it in your system (except that a header is added identifying
the time of reception and the call of the sending station).
Should a message for that station already be in the system,
yours should be appended to it. In the event the your upload
is aborted, the amount of text received before the abort
occurred should be stored as the message. There should also
be a stored note within the message stating that the upload
was aborted.
When you disconnect from the host station, its beacon will
be updated.
Once the message is loaded in the host, it can only be
deleted by the operator of the host station.
PK232COM Version 1.42.
All this and more is available for the IBM PC and clones in the
shape of PK232COM Version 1.42. As the program was first written
for the AEA PK232 TNC, and the data throughput at HF seems better
using AMTOR, it also contains AMTOR related robot functions.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 13
In this version of the program most of the packet features
described herein can be used by those owners of TNC2's or
compatables.
The major development, debugging and testing of PK232COM (Versions
1.00 to 1.41) took place in Jerusalem in the summer of 1987.
There the ROBOT station G3ZCZ/4X using just an FT-101 and a dipole
antenna operated on an intermittent shedule mostly overnight and
on weekends mainly on 20 Meters AMTOR and Packet until the power
supply transformer in the FT-101 smoked.
Amongst its achievements were;
* WAC in both Packet and AMTOR communications modes.
* It worked nearly 50 countries each on both AMTOR and Packet.
The computer said that it made 663 Packet connects with 371
different stations, and 526 AMTOR links with 330 different
stations. It even worked countries that I still I haven't,
usually because propagation was only present late at night
or very early in the morning, local time.
* A 10 day long AMTOR QSO between G3ZCZ/4X and VU2IJ in which
VU2IJ would link up, receive his message and leave a reply
which would be answered the following day.
* The first intra-Jerusalem (perhaps even intra-4X) AMTOR QSO
which took place between G3ZCZ/4X and 4X6AA. The unusual
part of the QSO was that both G3ZCZ and 4X6AA were operating
4X6AA, while the Robot was operating at G3ZCZ/4X.
* Pioneer Robot Propagation Beacon Experiment. The Robot put
out a CQ every 2 to 4 minutes when active. This must have
been the world's first HF Beacon station that could receive
propagation reports from listeners in real time. This was
not a mailbox. Whereas I (the beacon keeper) could leave
messages for anyone and did, others could only leave them
for me. Several stations contacted commented that they used
the robot as an indicator of propagation, and I could tell
by the log when propagation was present to DX areas.
If such Robot beacons were to replace the existing IARU HF
beacons, and were to be located in remote DX locations, I
feel sure that the QSL hunters would be more than glad to
work them and provide propagation reports in real time.
Acknowledgements.
I would like to acknowledge and thank the many radio amateurs
around the world for their help, suggestions and patience in the
design, testing and debugging of the many features of the prog-
ram.
(c) Joe Kasser 1987
PACKET RADIO - THE USER INTERFACE PAGE 14
References
1 From RTTY to Packets, Joe Kasser, G3ZCZ, First ARRL Amateur
Radio Computer Networking Conference, 1981.
2 Software for Amateur Radio, Joe Kasser, G3ZCZ, published by
TAB Books, Blue Ridge Summit, Pa. 17214 USA (Book number
1560).
3 YAPP, Yet Another Packet Program Version 2.0, Jeff Jacobsen,
WA7MBL.
4 PAKRATT Model PK-232 Multi-Mode Data Controller Operating
Manual, Advanced Electronic Applications, Inc.
(c) Joe Kasser 1987
